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SUMMARY 


The  Simogen  language  has  been  designed  specifically  to  provide  a  user- 
friendly  environment  for  computer  modellers.  It  is  a  heavily  object-oriented 
language,  beat  has  been  designed  to  be  easy  to  pick  up  for  the  most 
inexperienced  of  users,  rather  than  to  exploit  the  full  power  of  the  object- 
oriented  paradigm  in  all  cases.  This  paper  looks  at  the  reasons  why  it  was 
felt  necessary  to  create  a  new  language,  and  considers  the  reasons  behind 
the  particular  design  chosen.  It  also  describes  the  language  in  outline,  and 
discusses  briefly  to  what  extent  the  language  can  be  said  to  be  object- 
oriented.  Finally,  an  outline  is  given  of  a  possible  iconic  interface  for 
the  language,  to  ease  it's  use  still  further. 
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1.  INTRODUCTION 


The  S Imogen  language  has  been  developed  within  the  Battlefield  Systems  group 
at  the  Royal  Signals  and  Radar  Establishment,  Malvern.  It  was  designed  to 
provide  a  programming  language  for  users  of  the  Battlefield  Sensor  Simulator 
machine,  or  BSS.  The  language  aims  to  provide  a  framework  which  the  user  can 
map  his  problem  onto  quickly  and  easily.  A  survey  of  the  field,  and  of  the 
programming  paradigms  available,  indicated  that  object-oriented  techniques 
were  very  well  matched  to  this  type  of  task.  Thus  a  language  has  been 
designed  and  a  prototype  program  generator  implemented,  which  hopes  to 
provide  a  balance  of  the  pcwer  of  a  full  blcwn  object-oriented  language, 
such  as  Smalltalk,  and  the  simplicity  of  a  teaching  language  like  Pascal. 

Despite  being  written  for  a  very  particular  purpose  the  Simogen  language  is 
not  in  any  way  tied  to  a  particular  class  of  problem,  and  could  be  used  for 
a  whole  range  of  programming  applications.  The  program  generator  has  been 
developed  in  a  machine  independent  way,  to  run  on  most  machines  which  have  a 
C  compiler. 


2.  THE  S IMOGEN  LANGUAGE 


2 . 1  Why  a  new  language? 

For  the  last  few  years  RSRE  has  been  engaged  in  the  development  of  the 
Battlefield  Sensor  Simulator  (BSS) .  This  is  a  large  computer  system  which 
aims  to  completely  change  the  process  of  modelling  sensor  devices  on 
computers. 

Historically,  the  first  stage  in  testing  a  new  sensor  design  has  been  to 
build  a  physical  prototype.  If  testing  this  prototype  exposes  a  flaw  in  the 
sensor  design  there  will  be  a  need  to  revise  the  design,  and  then  a  further 
prototype  must  be  built  and  tested;  this  cycle  must  be  repeated  until  the 
design  is  found  to  be  satisfactory.  This  process  is  very  costly,  both  in 
terms  of  the  time  taken  to  go  round  each  iteration  of  the  loop,  and  in  terms 
of  the  money  spent  on  materials  and  labour  each  time  in  building  a 
prototype.  Thus  there  is  an  urgent  need  for  computer  simulation  of  such 
devices,  so  that  many  of  the  flaws  in  the  design  can  be  ironed  out  before 
the  first  real  model  is  built,  decreasing  the  number  of  re-designs  needed  at 
this  stage  and  lowering  the  cost. 

For  these  reasons  the  simulation  of  sensors  has  been  widely  carried  out  for 
many  years.  The  new  element  provided  by  the  BSS  is  a  drawing  together  of  the 
kinds  of  facilities  that  modellers  need.  In  general,  each  new  sensor  model 
is  written  from  scratch,  and  the  model  itself  becomes  inextricably  linked 
with  the  environmental  information  which  that  particular  sensor  requires  in 
operation.  Therefore  in  general  it  would  be  very  difficult  for  a  modeller  to 
take  an  existing  model  for  a  short  range  radar,  written  by  someone  else,  and 
to  adapt  it  for  his  requirement  of  modelling  a  long  range  bistatic  radar. 
Models  are  also  written  in  a  wide  range  of  languages,  and  often  cannot 
easily  be  ported  from  one  conputer  to  another. 

The  BSS  aims  to  alleviate  these  problems  by  providing  a  common  set  of 
facilities  to  ease  the  process  of  writing  models.  In  brief,  currently  the 
BSS  is  driven  by  a  detailed  scenario  of  48  hours  duration,  giving  the 
movements  of  vehicles  over  a  large  area.  The  BSS  also  provides  a  database  of 
a  range  of  information  about  the  terrain  within  this  area.  lastly,  there  are 
facilities  to  carry  out  intervisibility  calculations  for  the  user.  A  full 
description  of  the  BSS  is  given  in  [1]. 

The  BSS  is  unusual,  in  that  the  user  carries  out  all  his  modelling  on  his 
own  workstation  (in  this  case  a  workstation  may  be  quite  a  large  machine, 
such  as  a  Vax  11/780) ,  and  simply  asks  the  BSS  questions  to  obtain  the  data 
he  needs.  This  means  that  the  performance  of  the  whole  system  is  not 
severely  down-graded  if  one  user  runs  a  model  which  requires  a  great  deal  of 
processing  power. 

In  addition  to  the  facilities  described  the  BSS  system  provides  Simogen,  a 
special  programming  language  for  writing  the  sensor  models.  The  language  is 
designed  to  keep  the  balance  between  providing  all  the  constructs  needed  by 
modellers,  and  being  simple  enough  to  be  picked  up  quickly  and  easily. 
Beyond  this  Simogen  provides  not  only  the  means  of  writing  individual 
models,  but  also  the  necessary  tools  to  join  them  together  into  networks  of 
arbitrary  complexity. 

Library  models  written  in  Simogen,  will  be  provided  for  users  of  the  BSS 
system.  These  will  consist  of  generic  models  of  common  sensors  which  can  be 


tuned  to  represent  the  behaviour  of  the  users'  actual  sensor  simply  by 
providing  a  set  of  parameters. 


2.2  Factors  influencing  the  design  of  the  language 
2.2.1  The  Target  User 

The  Simogen  language  was  designed  to  aid  a  specific  group  of  people.  They 
are  a  mix  of  engineers,  operational  analysts,  and  people  from  other 
disciplines  with  the  common  goal  of  modelling  seme  device  or  group  of 
devices  in  order  to  find  the  answers  to  their  questions.  In  particular,  the 
people  using  the  BSS  would  normally  not  be  trained  programmers  or 
experienced  modellers.  Another  common  factor  among  the  users  is  likely  to  be 
that  of  having  only  a  few  weeks  to  learn  to  use  the  BSS,  carry  out  their 
simulation,  and  produce  the  results. 

These  points  meant  that  the  language  needed  to  be  very  simple  in  its  basic 
structure,  yet  at  the  same  time  provide  a  useful  framework  and  structure  to 
help  the  user  organise  his  thinking.  It  was  also  thought  useful  that  the 
language  should  resemble  existing  languages  where  possible,  for  example  by 
using  constructs  which  are  similar  syntactically  to  those  of  Pascal  or  C. 

Further  analysis  showed  that  there  were  a  set  of  highly  desirable  properties 
for  such  a  language 


a/  That  it  should  allow  the  decomposition  of  real-world  mechanical 
structures  into  a  set  of  "black  boxes"  which  communicate  strictly  defined 
ways.  This  property  is  important  because  engineers  tend  to  decompose  real 
systems  in  this  way. 

b/  That  the  'black  boxes'  can  be  further  broken  down  in  the  same  way  to  any 
number  of  levels,  to  reflect  the  way  a  real  item  of  equipment  can  be  seen  at 
several  levels  of  complexity. 

c/  That  the  boxes  can  operate  autonomously  (so  there  is  no  single  thread  of 
control  running  through  the  program) ,  and  that  they  appear  to  run 
concurrently.  This  is  an  important  feature  because  it  allows  a  model  to 
accurately  reflect  the  ordering  of  events  in  the  real  equipment. 

d/  That  the  user  can  create  a  black  box  with  the  properties  he  desires,  and 
then  replicate  this  as  many  times  as  he  wishes.  For  example,  to  model  a 
communications  network  he  might  define  the  black  box  for  one  node  in  the 
network,  then  create  a  running  program  with  20  copies  of  this.  In  many 
conventional  languages  this  would  not  be  so  easily  achieved,  and  the  user 
would  be  drawn  into  making  a  decision  on  hew  to  map  the  network  onto  the 
constructs  provided. 


These  requirements  indicated  that  many  of  the  properties  of  object- 
oriented  languages  would  be  very  appropriate  for  this  type  of  modelling.  A 
number  of  object-oriented  languages  were  considered  for  the  task  (for 
example  C++  and  Smalltalk)  and  did  indeed  have  very  useful  properties.  Their 
chief  drawback  was  that  they  required  considerable  initial  effort  in 
understanding  the  concepts  and  learning  to  use  them  For  the  particular 


application  involved  this  learning  tine  was  simply  not  available,  and  a 
simpler  alternative  was  needed. 


2.2.2  Portability 

As  mentioned  above,  the  Battlefield  Sensor  Simulator  system  requires  that 
the  user  provides  his  cwn  computer  to  run  his  model  on.  For  this  reason  a 
wide  range  of  machines  are  likely  to  be  used,  and  for  the  language 
recommended  for  use  on  the  BSS  to  become  a  useful  tool  and  provide  libraries 
of  sensor  models  for  users,  it  must  be  portable  to  all  these  machines.  This 
factor  further  limited  the  choice  of  modelling  language,  since  many 
languages  considered  were  sinply  not  available  on  a  wide  enough  range  of 
machines  (for  example,  the  Smalltalk  language  was  not  available  on  the 
Hewlett  Packard  machines  which  currently  make  up  the  majority  of 
workstations) . 

languages  such  as  Modula2  [3] [5],  and  Ada[6]  were  also  considered.  These  are 
not  strictly,  fully  object-oriented  in  every  way,  but  have  many  useful 
features  in  common  (for  example,  modularity) .  The  issue  of  portability’  again 
caused  problems  here,  since  neither  of  these  languages  were  available  on  the 
broad  spectrum  of  machines  needed. 


2.3  An  Outline  of  the 


S moqen  Language  Philosophy 

Since  no  listing  lcinguage  met  both  the  requirements  for  ease  of  use  and 
portabil  '  _y ,  it  was  decided  to  develop  a  new  language  to  meet  these. 
There  *" -re,  the  Simogen  language  (Simulation  Model  GENcrator) ,  draws  heavily 
or  the  object-oriented  paradigm,  but  attempts  to  avoid  complexity  and 
difficult  concepts  wherever  possible. 

A  program  in  Simogen  consists  of  any  number  of  objects.  The  object  consists 
»  of  data  space,  and  code  which  tells  the  object  hew  to  behave.  As  in  the 

majority  of  object-oriented  languages,  objects  communicate  by  passing 
messages  to  one  another;  a  message  consists  of  an  identifying  name,  and  any 
number  of  arguments  (but  the  number  and  types  of  these  arguments  is  fully 
defined  when  the  program  is  written).  In  Simogen,  an  object  reacts  to  a 
message  sent  to  it,  by  executing  its  response  for  that  message. 

A  Simogen  object  is  like  the  black  boxes  described  earlier;  its  internal 
variables,  and  the  way  in  which  it  works  are  not  visible  to  the  outside 
world,  and  the  only  way  to  communicate  with  it  is  by  sending  a  message  to 
it.  For  each  message  sent  to  an  object,  the  user  will  understand  the  effect 
of  this,  but  will  not  need  to  know  exactly  hew  it  is  achieved.  This  means 
that  an  object  can  be  fully  specified  to  other  objects  by  stating  : 

-  what  global  variables  it  declares 

-  what  types  are  defined  in  the  globals  section 

(this  is  only  needed  by  objects  which  are  defined  within  this  object) 

-  what  messages  it  is  able  to  receive 

-  what  messages  it  may  send,  and  to  which  objects 


This  property  of  encapsulation  of  data  and  the  code  to  act  upon  it,  is  very 
important  to  this  application,  since  the  usefulness  of  the  set  of  library 
sensors  provided  for  users  will  depend  heavily  on  the  ease  with  which  they 
can  be  interfaced  with  other  models,  and  configured  to  meet  the  users  needs. 
The  fact  that  objects  communicate  only  through  predefined  messages,  and  have 
no  way  to  alter  one  another's  data,  means  that  the  danger  of  unexpected  side 
effects  when  using  several  different  models  is  greatly  reduced. 

When  an  object  sends  a  message  in  Simogen,  it  does  not  wait  for  the  response 
for  that  message  to  complete,  but  continues  to  execute  independently.  Thus  a 
model  in  Simogen  consists  of  a  set  of  objects  which  appear  to  operate  in 
parallel  (this  is  not  actually  the  case  but  the  Simogen  scheduler  shares  the 
time  among  them  so  that  it  appears  to  be  so) .  This  feature  is  very  valuable 
in  a  lcinguage  for  simulating  the  real  world,  because  many  real  world  systems 
carry  out  several  activities  at  one  time.  Here  Simogen  deviates  from  the 
standard  object -oriented  paradigm,  since  there  is  normally  a  single  thread 
of  control  in  object-oriented  programs  (although  other  work  has  been  done  on 
combining  parallelism  with  object-oriented  ideas  [4]). 

Simogen 's  pseudo-parallelism  also  allcws  several  different  activities  to  be 
in  progress  within  a  single  object  at  any  time.  This  means  that  the 
programmer  must  take  care  to  ensure  that  a  particular  order  of  execution  is 
enforced  where  necessary;  although  this  may  seem  to  be  a  problem,  it  mimics 
the  problems  inherent  in  the  real  world.  Thus,  if  a  model  is  written  to 
represent  closely  the  behaviour  of  a  real  world  system,  the  points  where 
care  is  needed  on  the  part  of  the  programmer  are  likely  to  indicate  possible 
difficulties  in  the  real  system. 


In  Simogen,  the  code  which  describes  an  object  is  termed  its  definition. 
Once  an  object  has  been  defined,  Simogen  allows  the  user  to  declare  as  many 
'■.pies  (or  instances)  of  it  as  he  wishes;  each  of  these  will  have  its  own 
data  space  and  operate  completely  independently  of  the  others.  Each  instance 
of  a  Simogen  object  must  be  activated  before  it  can  receive  or  send  any 
messages,  and  may  be  terminated  when  it  is  no  longer  required. 

The  ability  of  one  object  to  declare  instances  of  another,  like  any  other 
data  type,  means  that  in  Simogen  objects  can  be  nested.  This  allows  the 
model  to  be  decomposed  in  the  same  way  as  the  engineer  views  the  real 
system.  For  example,  a  radar  could  be  modelled  as  a  radar  object,  which 
contains  4  other  objects  as  shown  :~ 


-the  Signal  Generator  object  would  be  responsible  for  generating  a 
representation  of  the  signal  that  this  type  of  radar  would  receive,  given 
information  on  the  environment  around  it.  It  would  then  pass  it  on  to  the 
Operator  Interface  for  displaying. 

-the  Scanner  would  represent  the  scanning  motion  of  the  radar.  Using 
information  on  the  arc  of  coverage  of  the  radar  aid  its  scanning  speed,  this 
could  calculate  at  any  point  in  time  the  orientation  of  the  radar. 

-the  Operator  Interface  would  provide  the  users  view  of  the  simulation, 
creating  a  screen  like  that  of  the  radar  being  simulated.  To  do  this  it 
would  take  the  returned  signal  calculated  by  the  Signal  Generator  and 
translate  this  to  a  screen  image  (trace) .  It  would  also  accept  user  commands 
to  change  parameters  of  the  radar  (for  example  the  scan  rate  or  scan 
pattern) . 

-the  Controller  object  would  provide  the  coordination  between  the  other 
objects,  converting  the  users  requests  from  the  Cperator  Interface  to 
messages  for  the  other  subsystems. 


Through  this  kind  of  approach,  the  object  concept  can  be  mapped  cleanly  onto 
the  sub-systems  of  the  equipment  being  simulated. 

The  ability  to  nest  objects  is  not  present  in  many  other  object-oriented 
languages,  but  provides  a  very  useful  structure  for  the  decomposition  of 
machinery.  It  can  oe  seen  as  analogous  to  the  top  down  functional 


decomposition  approach  in  procedural  languages,  which  provides  the  user  with 
a  powerful  method  of  breaking  down  large  problems  into  procedures  and 
functions  in  a  controlled  way.  In  S Imogen  problems  can  be  broken  down  in 
terms  of  objects,  which  not  only  reflect  the  activity  required,  but  can  also 
encapsulate  the  data  representing  the  current  state  of  this  part  of  the 
system  (in  a  procedural  language  any  persistent  data  would  usually  have  to 
be  stored  outside  a  given  procedure  and  passed  to  it  as  a  parameter) . 


2.4  Solving  the  Portability  Problem 

The  method  chosen  to  provide  the  necessary  portability  was  to  convert  the 
user's  program  in  Simogen  to  a  widely  available  programming  language,  and 
then  allow  the  compiler  for  this  language  on  the  user's  machine,  to  compile 
it  down  to  machine  code.  Clearly  the  Simogen  program  generator  must  also  be 
written  in  the  same  programming  language. 


In  this  case,  the  C  language  was  chosen,  for  the  following  main  reasons  : - 

-  The  C  language  is  very  widespread.  This  means  that  many  new  users  will 
already  has  a  C  compiler  on  the  machine  which  they  intend  to  use  for 
modelling.  Alternatively,  they  will  be  able  to  obtain  one  quite  cheaply  and 
easily. 

-  It  is  comparatively  standard  over  a  wide  range  of  machines.  Preliminary 
tests  have  shown  that  arbitrarily  large  and  complex  programs  can  be  ported 
between  a  range  of  machines  with  few  or  no  changes.  The  newly  formed  ANSI 
standard  for  the  C  language  should  help  further  in  this  area. 

-  C  is  a  fairly  simple  but  flexible  base  language.  It  has  a  comprehensive 
library  of  string  handling  routines,  common  to  most  implementations ;  this  is 
most  useful  for  the  large  amounts  of  text  processing  required  in  a  program 
generator  (much  of  the  C  code  output  is  formed  directly  by  copying  and 
manipulating  the  input  text) .  Its  simplicity  and  comparative  lack  of 
structure  also  makes  it  easy  to  create  the  program  generator  output  in  C, 
translating  from  the  Simogen  language  with  its  strong  modularity  and  special 
scoping  rules.  To  attempt  to  map  the  scoping  of  Simogen  onto  a  language 
wiiich  had  its  cwn  strong  rules  in  this  area,  might  be  considerably  more 
awkwar  ’ . 

•  The  simplicity  of  C  tends  to  lead  to  efficient  compilers  for  it,  allowing 
che  two  stage  translation  from  Simogen  to  machine  code  still  to  be 
'o  arplished  reasonably  quickly. 

The  internal  coding  of  each  section  within  an  object  is  procedural  and  quite 
conventional  in  nature.  It  was  felt  that,  whilst  the  object  paradigm  provide 
a  very  natural  of  decomposing  the  mechanical  world,  people  generally  seem  to 
describe  each  activity  which  a  piece  of  equipment  can  carry  out  as  a 
sequential  list  of  instructions .  Procedural  code  provides  the  closest 
mapping  to  this  way  of  describing  things. 


An  object  in  Simogen  is  divided  into  a  number  of  sections,  as  follows: - 


object  ORJ_NAME  is 

globals 

locals 

initialise 

responses 

demons 

definitions 

endobject  OBJ_NAME 


All  of  the  sections  are  optional.  Taking  the  sections  in  order 

-  the  globals  section  holds  those  variables  which  are  to  be  seen  by  other 
objects  outside,  but  which  cannot  be  altered  by  them.  The  globals  area 
might,  for  example,  be  used  to  store  the  position  in  grid  coordinates  of  a 
sensor  device  being  modelled,  so  that  other  devices  (modelled  as  objects) 
could  take  into  account  its  effects. 

-  the  locals  section  contains  the  declaration  of  variables  which  are  to  be 
visible  throughout  the  object,  but  invisible  outside  it. 

-  the  initialise  section  contains  program  code,  which  will  be  run  when  the 
object  is  activated.  This  piece  of  code  may  terminate,  or  may  contain  a  loop 
which  keeps  running  for  all  or  part  of  the  objects  life  (this  allows  the 
modelling  of  a  continuing  background  activity  in  an  object) . 

-  the  responses  section  tells  the  object  hew  it  must  respond  when  it 
receives  specific  messages.  Each  response  follows  the  form  : - 

on  message  [ MESS AGE_NAME ,  int  n,  char  c, . . . ] 
do 


Thus,  the  range  of  messages  which  a  given  object  can  receive  is  defined  at 
compile  time,  and  the  user  can  be  informed  at  this  point  of  any  unrecognised 
messages. 


-  the  demons  section.  A  demon  is  a  piece  of  code  which  can  be  set  to  execute 
whenever  a  particular  event  occurs.  It  takes  the  form  : - 


on  activation  of  OBJECT  NAME 


do 


or 

on  termination  of  OEJECT_NAME 
do 


on  change  in  VARIABL£_NAME 
do 


A  demon  can  be  set  on  any  variable  in  the  object  where  it  appears,  and  can 
be  triggered  on  the  activation  of  a  subobject,  the  termination  of  a 
subobject,  or  on  a  change  in  the  value  of  a  variable.  Demons  can  also  be  set 
on  the  global  variables  in  other  objects;  this  could  be  useful,  for  example, 
in  monitoring  the  movements  of  some  object.  Demons  could  also  be  useful  in 
developing  an  object  which  watches  the  changes  occurring  in  another  object 
when  debugging  a  program,  printing  out  useful  information  for  the  user.  Once 
the  program  is  operating  correctly,  the  debugging  object  can  simply  be  left 
out  without  any  other  change  to  the  code,  to  get  rid  of  the  debugging 
information. 

-  the  definitions  section  contains  the  definitions  of  any  sub-objects  and  of 
functions.  The  sub-objects  follow  exactly  the  same  format  as  their 
surrounding  object;  the  purpose  of  placing  the  subobject  definitions  inside 
this  object,  will  be  to  indicate  that  it  will  only  be  used  here  (these 
definitions  will  be  out  of  scope  outside  this  object) . 


2.5.1  Functions 

Functions,  in  Simogen,  can  be  defined  in  the  definitions  sections  of 
objects,  or  at  the  outermost  level  of  a  program.  They  are  not  the  main  means 
of  program  decomposition  as  in  Pascal  or  Modula,  but  are  provided  to  allow 
routines  used  frequently  within  an  object  to  be  written  once  as  a  function, 
and  also  to  allcw  access  to  existing  C  language  libraries  of  functions  for 
mathematics,  string  handling  etc. 


2.5.2 


To  conclude  the  section  on  Simogen  syntax,  an  example  is  given  bel cm  of  a 
very  simple  program  in  Simogen  : - 

startobject  CONTROL  controller; 


object  GIVE 

1 

object  TAKE  is 

initialise 

1 

1 

responses 

loop 

1 

on  message  [ITEM] 

begin 

1 

do 

send  [ITEM]  to  creator. taker; 

1 

printf  ("Thanks \n")  ; 

end 

1 

1 

endobject  TAKE 

endobject  GIVE 

! 

1 

object  CONTROL  is 
locals 

obj  GIVE  giver; 
obj  TAKE  taker; 
initialise 

activate  taker; 
activate  giver; 
endobject  CONTROL 


It  can  be  seen  that  the  program  is  divided  into  3  objects,  defined  as  GIVE, 
TAKE,  and  CONTROL. 

GIVE  repeatedly  sends  a  message  ITEM,  with  no  arguments,  to  TAKE. 

TAKE  consists  only  of  one  response,  which  receives  the  message  ITEM  and 
prints  "Thanks"  to  the  screen. 

The  OONTROL  object  serves  only  to  coordinate  the  other  two.  It  declares  an 
instance  of  each  of  GIVE  and  TAKE,  called  giver  and  taker  respectively,  and 
activates  them.  The  line  at  the  top  of  the  program  beginning 
"startobject. . "  tells  Simogen  which  object  is  to  be  activated  initially.  It 
is  then  the  responsibility  of  this  object  to  cause  the  activation  of  any 
other  objects. 

lastly,  the  GIVE  object  sends  its  message  to  "creator. taker";  creator  is  a 
predefined  object  identity  for  all  objects,  and  refers  to  the  object  which 
declared  and  activated  this  object.  Thus,  to  refer  to  taker  from  giver  it  is 
necessary  to  go  via  creator;  the  dot  operator  following  a  object  name  allows 
names  within  the  objects  scope  to  be  referenced  (this  is  the  means  by  which 
the  global  variables  of  another  object  are  referred  to) . 


In  modelling  the  real  world  it  is  often  important  to  be  able  to  dictate  the 
order  in  which  events  occur.  When  using  the  Battlefield  Sensor  Simulator  it 
is  also  necessary  for  the  user  to  be  able  to  synchronise  his  model  with  the 
passage  of  time  on  the  BSS.  Simogen  provides  two  measures  of  time,  realtime 
and  scenariotime,  the  first  represents  time  on  the  the  users  system,  and  the 
second  the  passage  of  time  in  seconds  through  the  BSS  scenario. 

Timing  can  be  controlled  by  means  of 

a/  The  delay  statement ,  which  causes  execution  of  the  particular  piece  of 
code  to  be  held  up  for  a  given  time 

b/  Appending  timing  information  to  the  sending  of  a  message,  for  example  :- 

send  [ITEM]  to  creator . taker  after  3  minutes,  4  seconds  realtime; 
or 

send  [ITEM]  to  creator . taker  at  10:20:30  scenariotime; 


2 . 6  How  object-oriented  is  Simogen? 

The  following  table  compares  some  of  the  main  features  of  Simogen  with 
Smalltalk. 


|  Smalltalk  |  Simogen 


Sees  the  world  as  objects 

l  yes  | 

I  I 

yes 

Communication  by  predefined  messages 

1  1 

|  yes  (methods) |yes 

1  1 

(responses) 

Many  instances  of  an  object  once  defined 

1  1 

|  yes  (classes) | 

i  i 

yes 

Inheritance 

1  l 

1  yes  | 

1  1 

no 

Dynamic  creation 

1  1 

|  yes  | 

1  1 

no 

To  summarise,  Simogen  has  many  of  the  features  of  an  object-oriented 
language,  but  omits  certain  key  properties  (notably  inheritance) .  It  has  a 
distinctly  object-oriented  flavour  to  it,  and  insofar  as  Ada  has  been 
considered  to  be  object-oriented,  Simogen  quite  definitely  is.  However,  it 
does  not  pursue  all  the  possible  object-oriented  properties  to  their  limit 
as  in  a  language  such  as  Smalltalk. 


3.  IDEAS  FDR  AN  ICONIC  USER  INTERFACE 

Early  in  the  history  of  computing  all  programs  had  to  be  written  in  machine 
code.  This  meant  that  the  programmer  needed  to  knew  in  detail  about  the 
architecture  of  the  machine  he  was  using  (for  example  the  number  of 
registers  provided,  their  size,  and  any  differences  in  their  function) . 
Computer  languages  have  evolved,  through  assembly  language  to  Fortran,  and 
then  on  to  Pascal-like  languages.  At  each  step  the  gap  between  the  user's 
perception  of  the  problem  to  be  solved,  and  the  way  in  which  he  must  express 
it  for  the  machine,  has  narrowed.  The  Simogen  language  closes  this  gap  still 
further  for  those  who  model  conplex  machinery,  by  providing  a  way  of 
structuring  programs  which  closely  reflects  their  view  of  the  problem.  The 
iconic  interface  will  try  to  provide  yet  another  level  of  abstraction  which 
allows  models  to  be  put  together  or  tuned  and  run,  without  any  understanding 
of  the  code  at  all. 

The  next  section  describes  a  possible  iconic  interface  for  Simogen. 

3.1  Some  possible  features  for  the  interface 

Working  with  the  iconic  interface  the  user  will  be  presented  with  a  set  of 
symbols,  each  of  which  represents  one  of  the  sensors  models  available  to 
him  (for  example,  one  might  be  a  small  picture  of  a  radar,  another  a  thermal 
imager) .  The  user  can  select  an  icon  by  moving  the  cursor  onto  it  (using  one 
of  number  of  input  devices,  for  example  a  mouse  or  special  keys  on  the 
keyboard) ,  and  can  then  move  it  to  group  it  with  others.  This  allows  him  to 
collect  together  all  the  different  sensor  models  which  he  wishes  to  use  in 
his  simulation.  He  can  also  display  a  map  of  part  of  the  BSS  area,  and  can 
position  the  icons  on  the  map  to  set  up  their  positions  (this  makes  it  easy 
to  select  a  location  for  a  sensor  quickly  and  visually  (the  user  can  simply 
locate  a  high  point  by  the  contour  lines  on  the  map,  and  move  the  sensor  to 
it)). 


The  user's  simulation  program  can  then  be  created  interactively.  After 
collecting  the  icons  which  he  wishes  to  use,  he  must  configure  the  models  to 
suit  his  needs  (default  values  will  be  provided  for  all  sensors,  so  that 
first  attempts  at  a  model  can  be  constructed  without  this  step) .  For  each 
different  icon  the  user  will  be  able  to  call  up  a  menu  which  will  allow  him 
to  select  from  a  list  of  the  operations  allowed  on  that  model.  This  might 
include  :  - 

View  details 

-  this  option  might  lead  to  a  screen  providing  basic  information 
on  the  object,  such  as  : - 
its  position, 

its  state  (probably  one  of  not  yet  activated, 

active, 

finished  (possible  only  when  an 
ob j  ect  cannot  respond  to 

any  messages) 
or  terminated) . 


View  spec 

-  Look  at  the  specification  of  the  object  in  terms  of  the  messages 
which  it  sends,  those  which  it  receives,  the  global  variables  it 
has,  and  what  objects  it  assumes  the  presence  of  (ie  which 
objects  it  sends  messages  to,  or  refers  to  the  global  variables 
of) 

View  settings 

-  This  could  ail  lew  the  user  to  look  at  the  settings  of  variables 
which  configure  the  particular  sensor  being  used,  and  alter 
these  if  required.  The  aim  of  this  is  to  provide  a  means  of 
tuning  existing  sensors  for  a  particular  simulation  without  the 
user  needing  to  read  and  understand  the  code  for  them.  The 
variables  included  here  might  be  those  in  the  object's  globals 
section.  An  example  of  this  might  be  the  case  where  the  user 
wishes  to  set  up  a  wired  communication  network.  Each  node  in  the 
network  might  have  the  settings 

My_Id  -  a  unique  string  which  can  be  used  to 
identify  this  node 

Rx  rate 

Tx  rate  -  the  rates  (probably  in  baud  units) ,  at  which 
the  node  will  receive  data  and  transmit  it 

Fail  Rate  -  a  measure  of  the  likelihood  of  the  node 
failing 

The  user  could  move  through  this  list  changing  values  to  his 

particular  desired  settings. 


Open 

-  look  at  and  if  necessary,  edit,  the  code  of  the  object  in  the 
BSS  language  (for  library  models  it  will  normally  be  possible 
for  the  user  to  edit  his  local  copy  of  the  code,  but  not  to 
change  the  library  version) . 

Activate 

-  start  an  object  running. 

Terminate 

-  Stop  an  object  running  (making  it  unable  to  receive  further 
messages. 

The  user  will  also  be  able  to  duplicate  an  icon  as  many  times  as  he  wishes 
to  create  several  separate  models  of  the  sensor  in  his  simulation. 

Finally,  he  will  be  able  to  connect  up  the  individual  sensor  models,  telling 
each  where  it  fits  into  the  overall  model,  and  which  others  it  is  to 
ocmmunicate  with  (for  example,  in  an  exercise  in  data  fusion,  the  sensor 
models  would  all  be  told  to  send  their  reports  to  the  same  fusion  object, 
which  would  then  attempt  to  correlate  them) .  The  user  could  then  call  up  a 
network  diagram  to  shew  the  links  which  he  had  set  up. 


The  iconic  interface  will  be  developed  under  the  X -windows  system  to  allcw 
porting  to  any  machine  which  supports  this.  It  will  hopefully  provide  a 
means  of  building  a  simulation  from  existing  models  without  the  user  needing 
to  deal  with  the  program  code  at  all. 


t 


4.  CONCLUSION7 


This  paper  has  described  the  principles  behind  the  programming  language 
Simogen.  The  degree  to  which  it  is  'object-oriented'  has  been  considered, 
and  the  conclusion  drawn  that  it  has  a  strongly  object-oriented  flavour,  but 
is  not  so  fully  object-oriented  as  languages  such  as  Smalltalk.  Finally 
ideas  for  an  iconic  interface  to  work  on  top  of  Simogen  and  allow  models  to 
be  created  without  the  need  for  any  programming  knowledge  at  all,  has  been 
described  briefly. 

A  prototype  compiler  for  Simogen  has  been  implemented  (with  one  or  two  minor 
omissions  ) .  It  currently  runs  on  Hewlett  Packard  9040,  and  350  machines, 
but  should  be  readily  portable  to  many  other  machines. 
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The  Simogen  language  has  been  designed  specifically  to  provide  a  user-friendly 
environment  for  computer  modellers.  It  is  a  heavily  object-oriented  language, 
but  has  been  designed  to  be  easy  to  pick  up  for  the  most  inexperienced  of  users, 
rather  than  to  exploit  the  full  power  of  the  object-oriented  paradigm  in  all 
cases.  This  paper  looks  at  the  re  sons  why  it  was  felt  necessary  to  create  a 
new  language,  and  considers  the  reasons  behind  the  particular  design  chosen.  It 
also  describes  the  language  in  outline,  and  discusses  briefly  to  what  extent  the 
language  can  be  said  to  be  object-oriented.  Finally,  an  outline  is  giver,  of  a 
possible  iconic  interface  for  the  language,  to  ease  it’s  use  still  further.' 
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